Previously, in REALbasic, the only type of declares you were allowed to use were hard declares. What this means is that when you write Declare Sub Foo Lib "Bar" (), you are telling REALbasic that Foo will always be in Bar, and Bar will always be installed on the user's system. So when building your application, we would put this dependancy in your application's Import table, and when the system loader tries to load your application, it will automatically find all of these declares and resolve them. If it couldn't resolve a library or a function from a library, your application would refuse to load and terminate.
Now, in RB 6, you are given a new construct called a "soft" declare. These declares are not put into your application's import table, and so the system loader doesn't try to resolve them. Instead, when you first try to use the softly declared method, REALbasic is responsible for resolving the library and functions. This provides you with a few handy features. First, it means that you now have a graceful way to deal with the situation of a function or library that isn't found (instead of your application just not launching, you now have an exception you can catch). Second, it means that we can be more flexible about loading the library up.
For example, LibC on many newer Linux distros is really a ld loader script that gcc uses to determine which version of LibC to actually link against. This means that you can't write hard declares that link against LibC in REALbasic because libc.so isn't really a symbolic link to the proper shared library (like most other .so files are). You would have to write declare against the actual LibC version you wanted, which provides for a very poor experience for users who don't have the same version of LibC installed as you. However, now that you have soft declares, we can resolve the loader script for LibC and find the proper shared library to load against. What this means in practical terms is that what used to be declared like this:
Declare Function getpid Lib "libc-2.3.2.so" () as Integer
Can now be declared like this:
Soft Declare Function getpid Lib "libc" () as Integer
This new functionality means that you no longer have to try to link against a specific version of that library.
Another good example of why Soft declares are good comes from the Windows world. On Windows, any function that uses a string will have two different versions, the A version, and the W version. This is the Win32 way of dealing with Unicode. The unfortunate part is that the W version of the method is usually only available on Windows NT machines (not 9x ones), which means that previously, you'd have to make two different versions of your application. Well, now in RB 6, you can do this:
Soft Declare Function MessageBoxA Lib "User32" ( hwnd as Integer, msg as CString, title as CString, flags as Integer ) as Integer
Soft Declare Function MessageBoxW Lib "User32" ( hwnd as Integer, msg as WString, title as WString, flags as Integer ) as Integer
try
Call MessageBoxW( hWnd, "This is a string that handles unicode", "Title here", 0 )
catch
Call MessageBoxA( hWnd, "This is a string that doesn't handle unicode", "Title here", 0 )
end
You can run this code on any Windows machine and it will always work. The reason is simple: if the wide char version (W version) is available, then your call will not throw an exception, and because of the WString data type, all your strings will be automatically converted into UTF-16 strings when passed into the function. However, if the call doesn't resolve because you're running on Windows 98 (or another 9x machine), then the exception will be thrown and will call thru to the ANSI (A version) of the function call.
One more neat thing about why soft declares are more powerful than regular declares: you now have the ability to call into Mach-O bundles from within a CFM application. For example, if you wanted to get at the BSD function called "socket", you can use a soft declare like this:
Soft Declare Function socket Lib "System.framework" ( domain as Integer, type as Integer, protocol as Integer ) as Integer
Finally, there is one last helper function to talk about: System.IsFunctionAvailable. This is simply a way for you to see if a function can be resolved without having to actually declare it and call into it.
So you're probably thinking, man, with all this power, there must be a huge performance hit over hard declares. Well, you're thinking wrong then. When the soft declare is first "noticed", we load and cache all the background information such as the library and the function pointer. So the only performance hit you will see is on the initial call of the declared function, or the call to IsFunctionAvailable. All subsequent calls are really quite fast due to the caching.
